In many different enterprises, multiple applications and data sources exist that create challenges in reconciling and managing a unified view of a data entity across the enterprise. For instance, data related to an entity such as customer or product is strewn across various systems (e.g., applications and data storages). Several of these systems have separate data repositories and thus store their own version of the entity data. In other words, the data storages of an enterprise might store multiple instances of a data record for a particular entity. This redundant data may cause problems for the enterprise that uses the data.
To overcome this issue, some enterprises maintain master data in a master data store. Master data represents the common or shared set of entities providing context for the transactions that occur in the enterprise across the various applications and data storages. For instance, in a sale transaction of 10 units of Widget A to customer Alpha, the transaction can only be fulfilled and processed by an enterprise if all systems in the enterprise share the consistent definitions of product definition (i.e., Widget A) and the customer (i.e., Alpha). Although the list is non-exhaustive, examples of entities include organizations, enterprises, companies, customers, individuals, services, accounts, products, etc.
The master data may include one or more master data objects, each master data object including a set of data attributes specified by the enterprise (e.g., data administrator, business user). In some enterprises, these data attributes are specified based on the reference data (i.e., data that identifies entities) of multiple different data sources. In addition to master reference data objects, some enterprises may also maintain a “best version” of relationship data (i.e., data that expresses a relationship between entities) for some or all the entities that are tracked by the enterprise. Additional description for master data and master data management is provided for in the U.S. patent application Ser. No. 11/957,398 filed on Dec. 12, 2007, now issued as U.S. Pat. No. 8,271,477, which is incorporated herein by reference.
When an enterprise attempts data integration or data sharing, a fundamental problem is how to define access control for allowing and restricting access to the master data. A conventional approach taken by many data integration solutions is to secure the master data using a standardized security access control model for the enterprise. One such model is a role based access control model.
In a role based access control model, roles are configured to specify certain level of access privileges to various entities of the enterprise based on the operations or functions performed by a particular entity. Each role defines specific access control permissions (e.g., read, write, merge, no access, etc.) to the various master data objects or individual data attributes of the data objects. For an enterprise that includes hundreds of different roles, administration of the role based access control can be simplified by adapting a hierarchical approach towards defining the access control permissions for each role. For instance, some of the following hierarchical relationships may be established to simplify security administration using a role based access control model: (1) a particular role may be associated with multiple different users, (2) a particular user may be associated with multiple different roles, (3) a particular access permission may be associated with multiple roles, (4) a particular role may be associated with multiple access permissions, or (5) access permissions defined for a parent role may be automatically inherited by a child role.
In an enterprise which requires the master data to be accessed by several different entities, role based access control provides security administration with a low overhead cost. A security administrator need not specify access rights for each user that enters or leaves the enterprise. Instead, the security administrator assigns a role to the user or a group of users and access rights are automatically associated with the role. Similarly, the security administrator need not specify access rights for each individual data attribute that is entered or modified within the various data objects.
FIG. 1 illustrates securing access to data using the role based access control model. In this figure, users 110 and 120 attempt to access data attributes of an accounts data object 130 that includes various data attributes represented by the various columns of the data object 130. Each user 110 and 120 is assigned a different role. Each role is provided with different access rights to all data attributes of the data object 130. Specifically, user 110 is assigned the role of a bank manager and is provided read and write access to the data attributes of the accounts object 130 based on the bank manager role. User 120 is assigned the role of a financial advisor and is provided less access to the data attributes of the accounts object 130 than the bank manager 110. In this figure, the role of the financial advisor is only privileged to read the data attributes within the accounts object 130, but not write to the data attributes of the accounts object 130.
However, role based access control has many shortcomings in providing adequate security access control in a large enterprise setting. Specifically, the “one size fits all” level of access provided to users assigned to the same role often provides too little access to those users that require additional access or too much data access to those users that should otherwise be restricted from access.
FIG. 2 illustrates some of the various shortcomings of the traditional role based access control model for securing master data or other data within an enterprise setting. As in FIG. 1, user 110 assigned the role of bank manager is provided read and write access to the data object 130 and user 120 assigned the role of financial advisor is provided only read access to the data object 130. However, both the first user 110 and second user 120 may have no need to view or should be restricted from accessing some of the various data instances within the data attributes (i.e., columns) of the accounts object 130.
For instance, assuming that the first user 110 is associated with a New York branch, then there may be no need to expose the account data of the California branch 210 to this user 110. However, the role based access control model does not provide sufficient granular security access control to effectuate such a restriction since the roles configure access permissions to the entire data object 130. Even if access permissions are configured for each data attribute (i.e., column) of the data object, the role based access control model would still provide insufficient access control to restrict a New York branch manager from accessing the account data of the California branch 210 (i.e., individual rows within the columns could not be restricted). As a result, the traditional role based access control model provides such users with access to potentially privileged or confidential data.
To provide the desired level of security through a role based access control model, the system administrator would have to create physically separate data objects or data views within the master data to distinguish the account data of the California branch 210 from the account data of the New York branch. The system administrator would then have to create separate financial advisor roles for the California branch different from financial advisor roles for the New York branch. To do so, creates administrative overhead and creates disjointed data in which data that was once grouped together becomes partitioned across multiple separate data sets with different data objects. Additionally, the different data objects may include data attributes that need to be made available to users in all branches. This creates redundancies in different objects and creates potential data synchronization issues. Therefore, the role based access control model presents a tradeoff between simple security administration and granular security access control.
A policy based access control model is an alternative security model implemented by various enterprises to restrict access to the master data of an enterprise. Unlike role based access control, policy based access control provides any desired level of access control over the data objects, the individual data attributes within each object, or the particular data instances within each data attribute by defining different rules or policies to apply to the different data objects, data attributes, data instances, or users accessing the data.
FIG. 3 presents a policy based access control implementation for controlling access to an accounts data object 340 of an enterprise 350 through a defined set of security policies 310. In this figure, two users 320 and 330 attempt to access data attributes (e.g., customer accounts) of the accounts object 340. The defined security policies 310 specify access rights for each user (e.g., user 320 and user 330). Specifically, three different security access policies are defined for a user that is defined the role of a California bank manager. A first access policy allows a California bank manager to view all accounts in the accounts object 340. A second access policy limits the first access policy by permitting the bank manager access to modify accounts in the state of California. A third access policy restricts the California bank manager from modifying accounts in other states. Similar access policies may exist for bank managers of other states depending on the level of security imposed on such users by the system administrator.
Three particular security access policies are also defined for a user that is defined the role of a California financial advisor. A first access policy is defined to permit a California financial advisor the ability to view all accounts in the state of California. A second access policy is defined to permit the California financial advisor the ability to view and modify accounts in the branch that the financial advisor owns. A third access policy is defined to permit the California financial advisor the ability to view and modify accounts that the financial advisor owns that are outside the state of California.
The traditional policy based access control model thus provides any level of granular security control desired by a security administrator. However, in order to achieve this level of security control, a shortcoming of the policy based access control model is exposed. Namely, the administrative overhead relative to role based access control is greatly increased. As evident in FIG. 3, the system administrator defines multiple security access policies for each single user or data attribute in order to specify the security access control for a single data object. For an enterprise with hundreds of different users, roles, data attributes, or data objects this level of administrative overhead quickly becomes unmanageable.
There is no obvious manner to combine the functionality of a role based access control model with the functionality of a policy based access control model. Policy access controls that are more granular than role based access controls will override the role based access controls when both security access control models are simultaneously applied. Such conflict prevents combining the two approaches for practical applications.
When the policy based access control does not override the role based access controls, the policy based access control conflicts with the role based access controls creating inconsistent access control enforcement. For instance, the role based access control specifies read only access to all data attributes of a data object, whereas the policy based access control specifies read only access to a particular data attribute of the data object, but read and write access to other data attributes of the data object.
Accordingly, there is need in the art for enterprise level security access control that provides sufficient granular control over the master data in the enterprise while minimizing the administrative overhead associated with providing such granular control. Moreover, such access control should be provided without significant cost or significant changes to existing systems, underlying business processes, and underlying business applications of the enterprise.